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Domain = Domain of the user (corps.com) 

AAA IP = IP Address of the domain's AAA. Corp A's AAA server 

Port# = Port on which the domain's AAA is listening to RADIUS requests 

Shared Secret = The shared secret that is to be used to hash the packets 

being sent to the domain's AAA 
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INTEGRATION OF AUTHENTICATION 
AUTHORIZATION AND ACCOUNTING 
SERVICE AND PROXY SERVICE 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to the field of data commu- 
nications networks. More particularly, this invention relates 
to a method and apparatus for unifying the operation of 
authentication, authorization and accounting services and 
proxy services in a data communications network. 

2. The Background 

ISPs (Internet Service Providers) and Telcos (telephone 
companies) typically offer wholesale internet access and 
retail internet access to their subscribers. Wholesale access 
is typically offered to subsidiary and specialized service 
providers, CLECs (Competitive Local Exchange Carriers), 
corporations, and Community of Interest (CGI) providers. 
Naturally, the processing afforded customers of the whole- 
sate variety differs from the processing afforded customers 
of the retail variety. Subscriber information for individual 
wholesale users is usually stored by those who lease data 
communications network access from the ISP or Telco. 
Hence, corporations, CLECs and COI providers do not 
normally share their user information with the wholesale 
providers. The ISP or Telco, however, typically also has its 
own retail subscribers whose user information is stored in its 
databases. Hence, the ISP or Telco must identify an incom- 
ing user as a wholesale user or a retail user and initiate 
different actions for an incoming user based upon this status. 

See, for example, FIG. 1 where a pure retail environment 
has a number of network access servers (NAS^, NASj and 
NAS3) which provide data communications portals to the 
ISP's point of presence (PoP) on the data communications 
network. Each NAS is in communication with a conven- 
tional AAA (authentication, authorization and accounting) 
service maintained by the ISP Incoming users connect to the 
NASes by dialing in over the telephone network or in 
another conventional manner 

Traditional wholesale ISPs and Roaming Service Provid- 
ers offer network access through a technique called 
"Authentication proxying." Proxying involves the transfer 
of the Authentication responsibility to the "owner** of the 
subscriber. Thus, if a corporation was to outsource its 
corporate intranet to an ISP, what it gives up is the mainte- 
nance of its dial-up servers (i.e., the NASes). It does not, 
however, normally want to give up the control or informa- 
tion of its employees. Hence, when a corporate user dials in 
to such an ISP's network access servers, the user essentially 
perceives that the user is dialing into a corporate facility 
when the user is actually dialing into the ISP's domain and 
then somehow gaining admittance to the corporation's intra- 
net. 

What really happens in that scenario is that the ISP 
determines that the user belongs to Corporation A(Corp^) by 
parsing either the fully qualified domain name (FQDN) 
supplied by the user, a DNIS ID, or some other mechanism. 
Having determined that the user trying to gain access 
belongs to Corp^, the ISP cannot really authenticate the user. 
As noted earlier, the user's record is still with the corpora- 
tion. Hence, the ISP will "proxy" out the authentication 
transaction to the corporation. An AAA service within the 
corporation then identifies the user, verifies the password, 
and provisions the user. Then the AAA service notifies the 
ISP's proxy server that the user is acceptable and passes 
along provisioning details associated with the user (such as 
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an IP address to use or a pool identification of an IP address 
pool from which an IP address needs to be allocated). The 
ISP then grants the user access to the network based upon the 
reply it gets back from the corporation. Tliis technique is 

5 called "proxying." This is shown in FIG. 2. 

To be able to do this, the ISP maintains minimal infor- 
mation on its proxy server 14 at its PoP. Information such as 
supported domain names, the IP address to which the 
transaction is to be sent, the port number to which the 
transaction is to be addressed, etc. are stored (see FIG. 3). 

For example, turning now to FIG. 2, user Joe@corpa.com 
dials in 40 to NAS^. A PPP (point to point protocol) session 
is raised between Joe and NAS,. An IPCP (internet protocol 
control protocol) session 42 is raised between NASj, and 
proxy service 44. In response NAS^ sends a RADIUS 
(Remote Authentication Dial -In User Service protocol) 
access-request to proxy service 44. Proxy service 44 then 
consults its local configuration database 16. Proxy service 
44 then makes a determination about where to send the 
access-request packet. Here it decides to send it to the AAA 

20 service 48 maintained in the Corp^ domain 50. The Corp^ 
AAA 48 then consults its local database 52 and authenticates 
joe@corpa.com. Corp^ AAA 48 then returns an access- 
accept packet to proxy service 44 which, in turn, sends an 
access-accept packet to NASj completing the log-in of 

25 joe@corpa.com. 

When the subscriber is granted access, or leaves the 
network, the accounting transactions will now have to be 
shared with the wholesale customers of the ISP/Telco. That 
is, the ISP/Telco will keep a record with which to bill or 

30 otherwise account to CorP^ for services rendered and the 
record will also need to be sent to Corps's AAA. Typically, 
the wholesale provider (e.g., the ISP) will use a roaming 
service product such as the Global Roaming Server"^** 
(GRS), a product of Cisco Systems, Inc. of San Jose, Calif., 

35 to achieve this objective. In the retail case, the ISP/Telco will 
use a product like Cisco Secure™, a product of Cisco 
Systems, Inc., to act as an authentication, authorization and. 
accounting (AAA) service to authenticate and authorize the 
user This approach, however, poses some problems for the 

40 ISP/Telco. 

The ISP/Telco needs to maintain two different sets of 
NASes as diagrammed in FIG. 4 or it has to pipe all 
transactions through a GRS (proxy service) as diagrammed 
in FIG. 5 which then has to make a decision as to whether 

45 the access-request transaction will be locally processed by 
the ISP/Telco (retail user) or remotely processed by the 
wholesale customer (wholesale user). The two products are 
independent products which maintain their own databases. 
They do not at present support a distributed architecture and 

50 hence will not scale by the number of PoPs users, etc. This 
poses the problem that multiple instantiations of the GRS 
will need to be configured and will not be able to properly 
load balance among the various NASes available at the PoP. 
Furthermore, should a GRS go down, the PoP may lose the 

55 services of the NASes in communication with the GRS that 
failed. 

Accordingly, it would be desirable to provide a capability 
for allowing ISPs and Telcos to seamlessly offer wholesale 
and retail data communications network access, unify the 
^0 disparate systems that specialize in these access control 
segments and scale both systems to simultaneously reside on 
a plurality of PoPs while behaving in a distributed manner 
within the data communications network. 

^5 SUMMARY OF THE INVENTION 

A single database maintained centrally hosts both proxy 
service data and authentication, authorization and account- 
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ing (AAA) data. Data is then copied to storage used locally invention wiD readily suggest themselves to such skilled 
by each system when both systems are instantiated. There- persons after a perusal of the within disclosure, 
fore the ISP/Telco need not maintain two different data In accordance with a presently preferred embodiment of 
bases. A protocol gateway (PGW) is used to determine if the the present invention, the components, processes and/or data 
incoming user is a wholesale or retail user. The PGW filters 5 stmctures are implemented using a gateway device and other 
the domain portion of the access request to locate a remote services implemented using C++ programs running on an 
AAA service. If one such service is found, the PGW routes Enterprise 2000''" server running Sun Solaris'^" its oper- 
Ihe communication via the GRS to proxy it to the remote ^ting system. The Enterprise 2000'^" server and Sun 
AAA service. The returned packet from the remote AAA Solaris™ operating system are products available from Sun 
service is then searched for an IP address to be assigned to lo Microsystems, Inc. of Mountain View, Calif. Different 
the incoming user, if one is not found the PGW obtains a implementations may be used and may include other types 
dynamically allocated IP address from a DHCP server (using operating systems computing platforms, computer 
TD n 1 irk f r J • *u * j i . r .u programs, firmware and/or general purpose machines. In 
an IP-Pool-ID .f supplied in the returned packet from the ordinary skill in the art will readily 
remote AAA service). The same mechanism is used to ^cognize that devices of a less general purpose nature, such 
forward accounting event packets from the NAS to the is as hardwired devices, devices relying on FPGA (field pro- 
remote AAA service. The PGW may monitor more than one grammable gate array) or ASIC (Application Specific Inle- 
proxy service and/or AAA service and load balance among grated Circuit) technology, or the like, may also be used 
'hem. without departing from the scope and spirit of the inventive 

concepts disclosed herein. 

BRIEF DESCRIPTION OF THE DRAWINGS 20 The protocol gateway (PGW or gateway) is a device 

HG. 1 is a system block diagram of a simple ISP PoP which couples the user via a network access server (NAS) to 

using a conventional retail-only paradigm. ^^e data communications network. The term gateway is not 

r.,^ ^ . , , , r , 1 , T^,^ meant to be limited to a single type or device, as any device, 

FIG. 2 IS a system block diagram of wholesale ISP PoP or software, that may act as a bridge between the 

using a conventional wholesale-only paradigm. ^5 user and the network may be considered a gateway for the 

FIG. 3 is a diagram illustrating the information main- purposes of this application. In accordance with a presently 

tained by a conventional proxy server. preferred embodiment of the present invention, the PGW is 

FIG. 4 is a system block diagram of an ISP PoP having ^ software service operating on a general purpose computer 

non-integrated retail and wholesale components. running the User Control Point (UCP) software package 

HG. 5 is a system block diagram of an ISP PoP using a 30 available from Cisco Systems, Inc. of San Jose, Calif. 

Global Roaming Server (GRS) proxy service to integrate authentication, authonzation and accounting (AAA) 

wholesale and retail functions, ^^^^ performs user authentication, user authorization and 

__ ^ . r TOT^ . user accounting functions. It may be a Cisco ACSTM 

nC. 6 IS a system block diagram of an ISP ^ produce such as Cisco Secure^M, available from Cisco 

protocol gateway (PGW) in accordance with a presently g ^^^^^ ^.^^^^^^ ^^^^^^ 

preferred embodiment of the present invention to integrate accordance with a presently preferred embodiment of the 

wholesale and retail functions and perform load balancing. ^^^^^^ .^^^^^.^^^ ^^^^^^ Authentication Dial-In User 

FIG. 7 is a system block diagram of an ISP NOC, broker Service (RADIUS) protocol is used as the communication 

publisher system and PoP in accordance with another pre- protocol between the gateway and the AAA and GRS proxy 

ferred embodiment of the present invention. services. RADIUS is an Internet standard track protocol for 

FIG. 8 is a system block diagram of a broker publisher carrying authentication, authorization, accounting and con- 
system used in accordance with a preferred embodiment of figuration information between devices that desire lo authen- 
the present invention. ticate their links and a shared AAA or GRS service. Those 

FIG. 9 is a flow diagram detailing a process by which the of ordinary skill in the art will realize that other Internet 

AAA service and its associated database are instantiated in 45 protocols such as TACACS+ can be used as acceptable 

accordance with a presently preferred embodiment of the authentication communications links between the various 

present invention, communications devices that encompass the data commu- 

HG. 10 is a flow diagram detaUing a process by which a nications network and still be within the inventive concepts 

proxy service and its associated database are instantiated in disclosed herem. The global roammg service (GRS) is also 

accordance with a presently preferred embodiment of the 50 a AAA service which is capable of praxying transactions to 

present invention remote AAA service. It also preferably uses the RADIUS 

FIG. 11 is a flow diagram detailing a user authentication protocol or an equivalent, 

and authorization process in accordance with a presently ^"^ ^^ich the present invention may come into 

preferred embodiment of the present invention. use mvolves the concep of roaming users. A roaming user 

. „ J. , .,. .... 55 IS, for example, a travelmg person with a lap top. If the 

FIG. 12 IS a flow diagram detailing a load balancing ^^^^ ,3 fga^h a corporate intranet or local ISP, he or 

process in accordance with a presently preferred embodi- ^^e can (1) dial the number of the home PoP (point of 

ment of the present mvention. presence) and incur potcntiaUy large telephone bilU; (2) dial 

FIG. 13 is a flow diagram detailing ao accounting process a "loll free" number such as an 800 number which can also 

in accordance with a presently preferred embodiment of the so be expensive— to the provider; or (3) use a global roaming 

present invention. server model. In the global roaming server model, ISPs with 

DETAILED DESCRIPTION OF TIIE '^^^T '°"-i°°f ■"f,* "'g^^^'"^'"* with one 

nnrr-T-rtnt-f^. r-x xh^fm* #t-xtt-o anothcr SO as to providc local telephone access numbers to 

PREFERRED EMBODIMENTS xon -^u * *u / az ■ .\ 

ISPs without any other (or a sufficient) presence in a 

Those of ordinary skill in the art will realize that the 65 location. To the user, it appears that his ISP has PoPs 

following description of the present invention is illustrative everywhere that there is a roaming agreement in place with 

only and not in any way limiting. Other embodiments of the a cooperating ISP. 
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A global roaming service ("GRS") at a PoP can parse the 
fully qualified domain name ("FQDN") of the user (e.g., 
joe@ISPA.NET) and determine that Joe belongs to ISFA- 
.NET. The GRS can then send an authentication request to 
ISPA.NET's AAA server to authenticate and authorize Joe in 5 
a conventional manner. Accounting event information, e.g., 
accounting start packets associated with log-in and account- 
ing stop packets associated with log-out, are sent both to the 
GRS at the local PoP and to ISPA.NET's AAA server to 
enable the local PoP to account for use by Joe at the local 
PoP and so bill ISPA.NET, if desired, and to allow ISPA- 
.MET to bill Joe, if desired. It also provides a mechanism for 
tracking this type of usage which can serve a number of 
purposes. 

GRSes have their own associated databases which keep 
lists of remote AAAs, their IP addresses, their port numbers 
and their associated domain names. 

To render the roaming model more tenable to the myriad 
IPSs and Telcos which might see fit to enter into these 
cross-agreements and thus make roaming easier for the end 
users, the process must be simpHfied and made scaleable. 20 
Under the prior model, as shown in FIG. 6, each GRS and 
AAA had its own associated stand -alone database which 
required maintenance from time to time. Multiple instances 
of such databases required individual maintenance. In many 
situations NAS resources were committed to a particular 25 
AAA or GRS at a PoP and not capable of load balancing. 

FIG. 7 is a system block diagram of an improved system 
in accordance with a presently preferred embodiment of the 
present invention. A data communications network 10 such 
as the internet, or an ISPs presence on the internet, or a 30 
corporate intranet, or the like, includes a network control 
console (NCC) 12 which is physically located on a host 14 
within a Network Operations Center (NOC) 16. The NCC 12 
is an application running on the host 14. The NCC 12 
monitors and manages the data communications system. The 35 
NCC 12 is in communication with a database 18 and an 
access database adapter 20. 

The database 18 and access database adapter 20 can run 
on the same host 14 as the NCC 12, as depicted in FIG. 7, 
or the database 18 and the access database adapter 20 can be 40 
located on more than one device. The database 18 stores 
information related to the various components and services 
comprising the data communications network 10 being 
managed. The system administrator accesses the informa- 
tion in the database 18, as needed, in conjunction with the 45 
NCC 12, to perform the overall network management task. 
The access database adapter 20 is in communication with 
both the database 18 and the NCC 12. This adapter, and 
other adapters in the invention, provide bi-directional map- 
ping of information between the NCC 12 and other services 50 
comprising the data communications network 10. Adapters, 
such as the access database adapter 20 subscribe to and 
publish events. An event is an independent entity which 
contains an unspecified amount of non-time critical infor- 
mation. For example, the access database adapter 20 55 
receives commands from the NCC 12 to pubhsh an event. 
The information contained in the event may be found in the 
NCC*s request or the access database adapter 20 may 
communicate with the database 18 to find the required 
information. A detailed discussion of some of the specific 60 
events pertinent to this invention and the information found 
therein is provided later in this disclosure. The event is then 
published to other services and components within the data 
network management system across an information bus 22 
which may be the data communications network itself. 65 

llie information bus 22 that serves as the transportation 
medium for the presently preferred embodiment of the 



present invention can be Common Object Request Broker 
Architecture (CORBA)-based. The CORBA-based informa- 
tion bus is capable of handling the communication of events 
to and from objects in a distributed, multi-platform envi- 
ronment. The concept of a CORBA-based information bus is 
well known by those of ordinary skill in the art. Other 
acceptable communication languages can be used as are also 
known by those of ordinary skill in the art. 

CORBA provides a standard way of executing program 
modules in a distributed environment. A broker 24, 
therefore, may be incorporated into an Object Request 
Broker (ORB) within a CORBA compliant network. To 
make a request of an ORB, a client may use a dynamic 
invocation interface (which is a standard interface which is 
independent of the target object *s interface) or an Object 
Management Group Interface Definition Language (OMG 
IDL) stub (the specific stub depending on the interface of the 
target object). For some functions, the client may also 
directly interact with the ORB. The object is then invoked. 
When an invocation occurs, the ORB core arranges so a call 
is made to the appropriate method of the implementation. A 
parameter to that method specifies the object being invoked, 
which the method can use to locate the data for the object. 
When the method is complete, it returns, causing output 
parameters or exception results to be transmitted back to the 
client. 

In accordance with a presently preferred embodiment of 
the present invention an Enterprise Application Integration 
(EAI) system is used to broker the flow of information 
between the various services and adapters comprising the 
data network management system of the present invention. 
An example of an EAI system that can be incorporated in the 
presently preferred invention is the Active Works Integration 
System, available from Active Software of Santa Clara, 
Calif. As shown in FIG. 8, such an EAI system 26 uses an 
information broker 24 as the hub of the system. The infor- 
mation broker 24 acts as the central control and storage point 
for the system. The information broker 24 can reside on a 
server and serves to mediate requests to and from networked 
clients; automatically queuing, filtering and routing events 
while guaranteeing delivery. The information broker 24 is 
capable of storing subscription information and using such 
subscription information to determine where published 
information is to be sent. Referring back to FIG. 7, the 
information broker 24 is shown as being located at a point 
along the information bus 22. In most instances the, broker 
will be located within the same NOC 16 as the host 14 that 
runs the NCC 12 application. Another key feature to the EAI 
system 26 of FIG. 8 is the use of adapters 28a, 2Hb, and 28c 
that allow users of the EAI system 26 to integrate diverse 
applications and other information when using the integra- 
tion system. Adapters 2Sa, 28Z), and 28c provide 
bi-directional mapping of information between an applica- 
tion's native formal and integration system events, enabling 
all custom and packaged applications, databases, and Inter- 
net and other network applications to exchange information. 
As shown in FIG. 8 the adapters 28fl, 286, and 28c run in 
association with the various services 30a, 306, and 30c from 
which information is published and subscribed on to an 
information bus 22 that has its hub at the broker 24, 

Referring back to FIG. 7 the information bus 22 is in 
communication with a Point of Presence (POP) 32 within 
the data communications network 10. The PoP 32 is one of 
many PoPs that the information bus 22 is in communication 
with. Located within PoP 32 is a host or node 34 which may 
comprise one or more computing devices on which some or 
all of the services shown in FIG. 7 may be running. The node 
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34 is in communication with the information bus 22 through NCC 12, The service adapters update their corresponding 

a control adapter 29 which provides control communications configuration files upon receiving a configure event. An 

with the various services 30a, 306, 30c, 30rf, 30e through example of the information contained within a configure 

their respective service adapters 28fl, 286, 28c, 2Sd, 2Se via event includes the GUID (global unique identifier) of the 
service adapter 31 of control adapter 29. 5 publisher, the GUID of the subscriber, listening port 

By way of example, the node 34 of FIG. 7 is configured configuration, sink port configuration, protocol handler 

with a PGW 30fl, an authentication, authorization and information, engine data and facility data, 

accounting (AAA) service 30c, a domain name system The NCC 12 publishes "start" events that are subscribed 

(DNS) service 30e, a dynamic host configuration protocol to by a control adapter such as control adapter 29 associated 
(DHCP) service 30d and a pair of GRS services 306. Those lO with a host computer at a node to cause the control adapter 

of ordinary skill in the art will appreciate that the services to start up one or more specific services. Since the control 

shown are not intended to be limiting and that other services adapter is always responsible for starting a service, the start 

and other service configurations can be used without depart- events are always subscribed to by the control adapters as 

ing from the inventive concepts herein disclosed. The sys- opposed to the service adapters. An example of the infor- 
tem services may also be distributed over two or more 15 mation contained within a start event includes the GUID of 

servers to provide improved performance and redundancy. the publisher, the GUID of the subscribing control adapter, 

The protocol gateway service 30a is used to couple the the GUID of the service to be started, the service name and 

network user to the data communication network. The the absolute path where the service binary resides. The 

protocol gateway service 30fl functions as an interface to the access database adapter 20 of the NCC 12 also publishes 

NASes that allows access requests received from a user to be "stop" events that are subscribed to by the control adapter to 

serviced using components that may communicate using cause the control adapter to shut down a specific service or 

different protocols. A typical protocol gateway service 30a multiple services. Since the control adapter is always 

may be able to support different user access methodologies, responsible for stopping a service, the stop events are always 

such as dial-up, frame relay, leased lines, ATM subscribed to by the control adapter as opposed to the 

(Asynchronous Transfer Mode), ADSL (Asymmetric Digital service adapters. Once the control adapter receives the stop 

Subscriber Line) and the like. Used in conjunction with the event, it publishes a stop event to the service adapter of the 

protocol gateway service 30a, the AAA service 30c per- corresponding service. The control adapter allows the ser- 

forms user authentication, authorization and accounting vice suflBcient time to shut down. If the service does not 

functions. The AAA service 30c stores user profile informa- respond to the stop event and continues running the control 

tion and tracks user usage. The profile information stored in adapter can explicidy kill the service based on the process 

the AAA service 30c is proxied to the protocol gateway ID found in the configuration file. An example of inform a- 

service 30a when a network user desires network access. tion contained within a start event includes the GUID of the 

The DNS service 30e is used to return Internet protocol pubUsher, the GUID of the subscribing control adapter, the 

(IP) addresses in response to domain names received, for GUID of the service to be stopped and the name of the 

example, from a protocol gateway service 30a. For example, service to be stopped. 

if the DNS service M)e receives a domain name query from Other events may be published and subscribed to. 

the protocol gateway service 30a, it has the capabiHty to The configure event is used to publish the current contents 

locate the associated numerical IP address from within the of a master database relevant to GRS and AAA services at 

memory of the DNS service (or another DNS service) and the various nodes of the data communications network. Thus 

return this numerical IP address to the protocol gateway the master database may be maintained and serviced at the 

service 30a. NOC or some other convenient facility and the AAA ser- 

The DHCP service ^Od is used as a dynamic way of vices and GRS services updated with information autoraati- 

assigning IP addresses to the network users as well known cally without the need to manually update their separate 

to those of ordinary skill in the art. databases. 

Each of these services 30a, 306, 30c, 30^/, 30e is in The PGW is used as a protocol gateway between the 

communication with a corresponding service adapter 28a, NASes and the AAA and GRS services. The PGW parses the 

286, 28c, 2Sd, 28e. The service adapter subscribes to and FQDN of incoming users and sends access requests from 

publishes various events on the information bus 22. The local users to the local AAA and access requests for roaming 
service adapter is configured so that it subscribes to events 50 users to the GRS. The GRS, in turn, forwards the access 

published by the access database adapter 20 of the NCC 12. requests to the remote AAA belonging to the user's provider 

The service adapter also publishes events to the access in accordance with the conventional proxy model, 

database adapter 20 of the NCC 12. The PGW has the ability to load balance by monitoring 

The following is an exemplary listing and definition of the condition and response times of its respective GRS 
some of the events published by and subscribed to by the 55 services and AAA services. Thus, if one such services is 

access database adapter and the service adapters which are particularly loaded, incoming calls may be directed to other 

pertinent to this invention. This listing is by way of example services. If one such server has crashed or becomes non 

and is not intended to be exhaustive or limiting in any way. responsive, it may be bypassed. In the present configurations 

Other events are possible and can be used in this invention where NASes are directly connected to a GRS and or an 
without departing from the inventive concepts herein dis- 60 AAA service, a dead service can result in the NASes 

closed. connected to the dead service becoming non-responsive. 

The NCC 12 publishes "configure" events to the service This condition is avoided by using the PGW as a front end 

adapters 28a, 286, 28c, 2Sd, 28c. Configure events are to the GRS and AAA service. 

published to configure the service adapters upon initial start In accordance with the present invention IP addresses may 
up of the service adapters or to modify a preexisting con- 65 be assigned to incoming users in a number of ways. For 

figuration. A configure event can be delivered to a service users having permanently or otherwise allocated IP 

adapter directly from the access database adapter 20 at the addresses . reflected in their user service profiles in their 



10/16/2003, EAST version: 1.04.0000 



us 6,298,383 Bl 



10 



respective AAA services, they will receive that address. This 
is done by returning the IP address in the access- accept 
packet ultimately returned to the NAS via the PGW. 

For users of the local ISP who do not have pre-allocated 
IP addresses, a DHCP (dynamic host control protocol) 5 
service such as one running in a host at the PoP will provide 
a DHCP IP address from a pool of such addresses assigned 
to the ISR 

For wholesale users, an IP address may be returned from 
a DHCP service running remotely at their provider, it may be -,0 
assigned by the ISP as if the user were a retail user of the ISP, 
or a separate pool of IP addresses maintained locally at the 
ISP on behalf of the provider can be identified by the 
access-accept packet and an address selected therefrom by 
the local DHCP service. ^5 

TUming now to FIGS. 9-12, FIG. 9 is a flow diagram . 
detailing the process whereby the AAA service and its 
database at a PoP are instantiated. The AAA service is 
preferably started (100) with a command entered at the NCC 
12 within NOC 16. The start command is passed over 20 
information bus 22 to information broker 24 which pub- 
lishes it to subscribing entities such as a control adapter at 
the PoP. The control adapter responds by starting the pro- 
cess. Once the process is started a configure command at the 
NCC causes publication (102) of database elements which 25 
are used to populate (104) the database of the AAA service 
at the PoP. This is preferably done using the broker-publisher 
mechanism described above with the AAA service or its 
database being the subscriber to the published information. 
FIG. 10 details a similar process for loading the database of 30 
a proxy or GRS server at the PoP. 

FIG. 11 details the process whereby a user is authenticated 
and authorized in accordance with a presently preferred 
embodiment of the present invention. At reference numeral 
112 the user attempts a log-in by dialing in to a NAS at the 35 
PoP At reference numeral 114 the network access request 
from the NAS is forwarded to a protocol gateway for 
processing. At reference numeral 116 the protocol gateway 
parses the FQDN of the user. If the FQDN indicates that the 
user's domain is processed directly at the PoP's AAA 40 
service, then the access request is forwarded there (118). 
Processing proceeds in a conventional manner. If the FQDN 
indicates that the user is to be authenticated remotely, then 
at reference numeral 120 the protocol gateway forwards the 
network access request to a proxy server or GRS server at 45 
the PoP for proxy processing. At reference numeral 122 the 
proxy/GRS server looks up the user's domain AAA contact 
information (e.g., address, port number) from the database 
associated with the proxy/GRS server and populated as 
described above. At reference numeral 124 the proxy/GRS 50 
server proxies the access request to the now-identified 
remote AAA service at the user's domain site. Processing 
proceeds in a conventional manner from this point on. 

FIG. 12 details the flow of the process by which the 
protocol gateway may load balance among multiple instan- 55 
tiations of AAA services and/or GRS/proxy services. At 
reference numeral 126 the protocol gateway maintains a 
database indicative of the responsiveness of the various 
AAA services and proxy/GRS services with which it is in 
contact at the PoP. Since it is sending requests to the services 60 
aU the time as users attempt to log-in, and because the 
service must acknowledge receipt of the requests in a 
conventional manner, it is a simple matter to determine the 
response time of the service at any given moment. Also, 
since the protocol gateway is feeding all of the access 65 
requests to their respective services, it is simple to track how 
many are being forwarded at any given time at the PoP. 



At reference numeral 128 the protocol gateway load 
balances by distributing network access requests among the 
relevant services in a manner designed to more or less 
equally share the load. Any convenient mechanism may be 
used, such as a round-robin schedule or another conven- 
tional scheduling algorithm. 

At reference numeral 130 the protocol gateway detects 
non-responsive services and bypasses them. An error con- 
dition event may also be published to allow other compo- 
nents of the data communications network to become aware 
of the failure. 

Turning finally to FIG. 13 a flow diagram of a process 
whereby accounting event records are distributed is shown. 
At reference numeral 132 an accounting event is detected. 
This could be, for example, an accounting start event or an 
accounting stop event detected at the protocol gateway. At 
reference numeral 134 the nature of the connection is 
determined. If it is a local user of the PoP, then the 
accounting event information is sent only to the local AAA 
service at reference numeral 136. If it is a proxy user, then 
at reference numeral 138 the accounting event is sent both 
to the local AAA service as well as to the proxied AAA 
service. 

Alternative Embodiments 

While embodiments and applications of the invention 
have been shown and described, it would be apparent to 
those of ordinary skill in the art, after a perusal of the within 
disclosure, that many more modifications than mentioned 
above are possible without departing from the inventive 
concepts herein. The invention, therefore, is not to be 
restricted except in the spirit of the appended claims. 

What is claimed is: 

1. A method for managing network access to a data 
communications network, said method comprising: 

maintaining a central database; 

maintaining at least one authentication, authorization and 
accounting (AAA) service at a point of presence (PoP) 
of the data communications network; and 

configuring a database associated with the AAA service 
from the central database, wherein said configuring 
includes publishing information from said central data- 
base on an information bus as at least one event, said 
AAA service subscribing to said event so as to receive 
said published information so as to thereby update its 
associated database. 

2. A method in accordance with claim 1, further compris- 
ing: 

receiving at a protocol gateway in the PoP a network 
access request fi-om a user through a network access 
server (NAS); 

parsing the network access request for an identification of 

the user's domain; 
routing the network access request to the AAA service at 

the Pop if the user's domain corresponds to that of the 

PoP; 

looking up a domain identification entry corresponding to 
the user's domain in the AAA service's database if the 
user's domain does not correspond to that of the PoP; 

proxying the network access request to an AAA service in 
the user's domain at an address and port as specified in 
the domain identification entry of the database if the 
user's domain does not correspond to that of the PoP. 

3. A method in accordance with claim 2, further compris- 
ing: 

obtaining an IP address for the user from the AAA service 
in the user's domain if the user's domain does not 
correspond to that of the PoP. 
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4. A method in accordance with claim 2, further compris- 
ing: 

assigning an IP address to the user from a local DHCP 
pool of IP address if the user's domain does not 
correspond to that of the PoP. 5 

5. A method in accordance with claim 2, further compris- 
ing: 

assigning an IP address to the user from an IP address pool 
identified in an access-accept packet received from the 
user's domain's AAA service if the user's domain does 
not correspond to that of the PoR 

6. A method for managing network access to a data 
communications network, said method comprising: 

maintaining a central database; 

maintaining a plurality of authentication, authorization 
and accounting (AAA) services at a point of presence 
(PoP) of the data communication network; and 

configuring databases associated with the AAA services 
from the central database, wherein said configuring 20 
includes publishing information from said central data- 
base on an information bus as at least one event, said 
AAA services subscribing to said event so as to receive 
said published information so as to thereby update their 
associated databases. 



15 



7, A method in accordance with claim 6, further compris- 
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45 



ing: 

receiving at a protocol gateway in the PoP a network 
access request from a user through a network access 
server (NAS); 30 

parsing the network access request for an identification of 
the user's domain; 

routing the network access request to one of said plurality 
of AAA services at the PoP if the user's domain 
corresponds to that of the PoP while load balancing ^5 
among said plurality of AAA services; 

looking up a domain identification entry corresponding to 
the user's domain in one of said plurality of AAA 
service's databases if the user's domain does not cor- 
respond to that of the PoP; 

proxying the network access request to an AAA service in 
the user's domain at an address and port as specified in 
the domain identification entry of the database if the 
user's domain does not correspond to that of the PoP. 

8. A method in accordance with claim 7, further compris- 
ing: 

obtaining an IP address for the user from the AAA service 
in the user's domain if the user's domain does not 
correspond to that of the PoR 

9. A method in accordance with claim 7, further compris- 
ing: 

assigning an IP address to the user from a local DHCP 
pool of IP address if the user's domain does not 
correspond to that of the PoR 55 

10. A method in accordance with claim 7, further com- 
prising: 

assigning an IP address to the user from an IP address pool 
identified in an access-accept packet received fi-ora the 
user's domain's AAA service if the user's domain does 60 
not correspond to that of the PoP. 

11. A method for managing network access to a data 
communications network, said method comprising: 

maintaining a central database, said central database con- 
taining access information for authentication, authori- 65 
zation and accounting services associated with domains 
of the data communications network; 



maintaining at a point of presence (PoP) of the data 
communications network at least one AAA service and 
at least one proxy service and at least one protocol 
gateway in communication with a network access 
server (NAS); 

periodically publishing information contained in said cen- 
tral database; 

subscribing at said AAA and said proxy service to infor- 
mation published from said central database; 

receiving at a protocol gateway in the PoP a network 
access request from a user through a network access 
server (NAS); 

parsing the network access request at the protocol gate- 
way for an identification of the user's domain; 

routing the network access request to an AAA service at 
the PoP if the user's domain corresponds to that of the 
PoP; 

looking up access information within a domain identifi- 
cation entry corresponding to the user's domain in a 
database associated with the proxy server if the user's 
domain does not correspond to that of the PoP; and 

proxying the network access request to an AAA service in 
the user's domain at an address and port as specified in 
the access information if the user's domain does not 
correspond to that of the PoP. 

12. A method in accordance with claim 11, further com- 
prising: 

obtaining an IP address for the user from an AAA service 
in the user's domain if the user's domain does not 
correspond to that of the PoP. 

13. A method in accordance with claim 11, further com- 
prising: 

assigning an IP address to the user from a local DHCP 
pool of IP address if the user's domain does not 
correspond to that of the PoR 

14. A method in accordance with claim U, further com- 
prising: 

assigning an IP address to the user from an IP address pool 
identified in an access-accept packet received from the 
user's domain's AAA service if the iiser's domain does 
not correspond to that of the PoP. 

15. A method of managing network access requests to a 
data communications network, said method comprising: 

receiving at a protocol gateway in a point of presence 
(PoP) of the data communications network a network 
access request from a user through a network access 
server (NAS); 

parsing the network access request for an identification of 
the user's domain; 

routing the network access request to one of the plurality 
of authentication, authorization and accounting (AAA) 
services associated with the PoP if the user's domain 
corresponds to that of the PoP while load balancing 
among the plurality of AAA services; 

looking up a domain identification entry corresponding to 
the user's domain in a database if the user's domain 
does not correspond to that of the PoP; 

proxying the network access request via one of a plurality 
of proxy services to an AAA service in the user's 
domain at an address and port as specified in the 
domain identification entry of the database if the user's 
domain does not correspond to that of the PoP while 
load balancing among the plurality of proxy services. 
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16. A method in accordance with claim 15, further com- 
prising: 

obtaining an IP address for the user from the AAA service 
in the user's domain if the user's domain docs not 
correspond to that of the PoP. 

17. A method in accordance with claim 15, further com- 
prising; 

assigning an IP address to the user from a local DHCP 
pool of IP address if the user's domain does not 
correspond to that of the PoR 

18. A method in accordance with claim 15, further com- 
prising: 

assigning an IP address to the user from an IP address pool 
identified in an access-accept packet received from the 
user's domain's AAA service if the user's domain does 
not correspond to that of the PoP. 

19. A method for managing network access to a data 
communications network, said method comprising: 

maintaining a central database, said central database con- 
taining access information for authentication, authori- 
zation and accounting services associated with domains 
of the data communications network; 

maintaining at a point of presence (PoP) of the data 
communications network a plurality of AAA services at 
least one AAA service and at least one proxy service 
and at least one protocol gateway in communication 
with a network access server (NAS); 

periodically publishing information contained in said cen- 
tral database; 

subscribing at said AAA and said proxy service to infor- 
mation published from said central database; 

receiving at a protocol gateway in the PoP a network 
access request from a user through a network access 
server (NAS); 

parsing the network access request at the protocol gate- 
way for an identification of the user's domain; 

routing the network access request to one of said plurality 
of AAA services at the PoP if the user's domain 
corresponds to that of the PoP while load balancing 
among said plurality of AAA services; 

looking up access information within a domain identifi- 
cation entry corresponding to the user's domain in a 
database associated with one of said plurality of proxy 
services if the user's domain does not correspond to 
that of the PoP while load balancing among said 
plurality of proxy services; and 

proxying the network access request to an AAA service in 
the user's domain at an address and port as specified in 
the access information if the user's domain does not 
correspond to that of the PoP. 

20. A method in accordance with claim 19, further com- 
prising: 

obtaining an IP address for the user from an AAA service 
in the user's domain if the user's domain does not 
correspond to that of the PoP. 

21. A method in accordance with claim 19, further com- 
prising: 

assigning an IP address to the user from a local DHCP 
pool of IP address if the user's domain does not 
correspond to that of the PoP. 

22. A method in accordance with claim 19, further com- 
prising: 

assigning an IP address to the user from an IP address pool 
identified in an access-accept packet received from the 
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user's domain's AAA service if the user's domain does 
not correspond to that of the PoP. 

23. A method of managing network access requests to a 
data communications network, said method comprising: 

receiving at a protocol gateway in a point of presence 
(PoP) of the data communications network a network 
access request from a user through a network access 
server (NAS); 

parsing the network access request for an identification of 

the user's domain; 
routing the network access request to an authentication, 

authorization and accounting (AAA) service associated 

with the PoP if the user's domain corresponds to that of 

the PoP; 

looking up a domain identification entry corresponding to 
the user's domain in a database if the user's domain 
does not correspond to that of the PoP; 

proxying the network access request to an AAA service in 
the user's domain at an address and port as specified in 
the domain identification entry of the database if the 
user's domain does not correspond to that of the PoR 

24. A method in accordance with claim 1, further com- 
prising: 

obtaining an IP address for the user from the AAA service 
in the user's domain if the user's domain does not 
correspond to that of the PoP. 

25. A method in accordance with claim 1, further com- 
prising: 

assigning an IP address to the user from a local DHCP 
pool of IP address if the user's domain does not 
correspond to that of the PoP. 

26. A method in accordance with claim 1, further com- 
prising: 

assigning an IP address to the user from an IP address pool 
identified in an access-accept packet received from the 
user's domain's AAA service if the user's domain does 
not correspond to that of the PoR 

27. A system for data communications network access 
management, comprising: 

a central database containing information identifying 
access information for authentication, authorization 
and accounting (AAA) services associated with 
domains of the data communications network; 

a publisher, said publisher publishing information from 
said central database to subscribers over an information 
bus; 

a point of presence (PoP) on the data communications 
network, said PoP including a protocol gateway in 
communication with at least one network access server 
(NAS); 

an AAA service associated with said PoP and in commu- 
nication with said protocol gateway, said AAA service 
subscribing to information published by said publisher; 
and 

a proxy service associated with the PoP and in commu- 
nication with said protocol gateway, said proxy service 
subscribing to information published by said publisher, 

said protocol gateway receiving network access requests 
from users over the NAS, parsing the requests for 
domain identification and routing the requests for 
domains other than those associated with the PoP to the 
proxy service, 

said proxy service routing network access requests to 
AAA services in remote domains in accordance with 
said access information. 
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28. A system in accordance with claim 27, further com- 
prising: an AAA database associated with said AAA service; 
and a proxy database associated with said proxy service, 

said AAA database populated at instantiation of said AAA 

service by receiving information published by said 

publisher from said central database, 
said proxy database populated at instantiation of said 

proxy service by receiving information published by 

said publisher from said database. 

29. A system for data communications network access 
management, comprising: 

a central database containing information identifying 
access information for authentication, authorization 
and accounting (AAA) services associated with 
domains of the data communications network; 

a publisher, said publisher publishing information from 
said central database to subscribers over an information 
bus; 

a point of presence (PoP) on the data communications 
network, said PoP including a protocol gateway in 
communication with at least one network access server 
(NAS); 

a plurality of AAA services associated with said PoP and 
in communication with said protocol gateway, said 
AAA services subscribing to information published by 
said publisher; and 
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a plurality of proxy services associated with said PoP and 
in communication with said protocol gateway, said 
proxy services subscribing to information published by 
said publisher, 

said protocol gateway receiving network access requests 
from users over the NAS, parsing the requests for 
domain identification and routing the requests for 
domains other than those associated with the PoP to one 
of said plurality of proxy services while load balancing 
among them, 

said proxy service routing network access requests to 
AAA services in remote domains in accordance with 
said access information. 

30. A system in accordance with claim 29, further com- 
prising: 

a plurality of AAA databases associated with said respec- 
tive AAA services; and 

a plurality of proxy databases associated with said respec- 
tive proxy services, 

said AAA databases populated at instantiation of said 
respective AAA services by receiving information pub- 
lished by said publisher from said central database, 

said proxy databases populated at instantiation of said 
respective proxy services by receiving information 
published by said publisher from said database. 



10/16/2003, EAST version: 1.04.0000 



